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ABSTRACT 


The demand for software products has grown, but the 
number of quality orogrammers has not kept pace. 
Therefore, programmer prodcutivity aas become a major area 
of discussion throughout the software developmant industry. 
This paper z2xamines the various aesasures discussed in the 
literature and used in salected corporations which develop 
software. It presents several methods for measuring 
programmer productivity. [ncluded in the discussion are the 
Salient points where manajy2rs must jlevote special attention 
‘tf they are +9 use programmer productivity measures effec- 
tively. Ties Beper is part of 3a group of papers which 
together provide recommsadations t> the Flast Material 
Support Office (FMSO) t9 enhance its software development 


organization. 
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I. LN TRODUCTION 


In the past two decad2s, as computer hardware costs have 


fallen and software costs have risen, there has been an 
gncredsizg interest in programnec productivity. This 


anterest has become particularly intense during the last 
decade as the general purposes computer market has flour- 
ished. Customers are becoming much more aware of the 
Peekyor tity that differsnt softwar> packages provide to 
computer hardware. They, therefore, are demanding more and 
more software products to upgrade @xisting hardware facili- 
ties. SOersaton feet. Ii cf Azrthizr oD. Little Ince., 4 
Caabridae (Mass.) consulting fira, States that the throt- 
Meitg “EaeGtOr in the evolution of the data processing 
=ndustry is the pace of software jJevelopment. Revenues in 
the data processing industry are expected to reach $95 
Dillion by 1984 but have the potential to reach $125 billion 


ct 


if the sctitwar Gad NOt -%ict. Phas 


(D 


developmeiat coiastr2ii 


(Qu 


Software demand has precioitated a large demand for progran- 
mers. But programmers, @2specially scilled ones, are hard to 
Pind “and take t#f@e t0 train. Since there has been such an 
Seetemom=scal growth in the computer software industry, 
finding sufficient numbers of well trained and experienced 
Peo ememmccos 2S prohibitively difficult. [Ref. 2], According 
fo Dedgieal Bauiphent Corporation “Ref. 3], the biggest 
Does 2S i2deneiiying <=he few gooli programmers. Otech= 
many applicants tney szec2ive, most are not capable of 
weiting sophisicated software. Tonsequently, sottware 
GeWe opers are urning towards increasing the productivity 
of programmers in an attsnpt £9 keep ovace with the demand 


for current and future software design needs. 








There have been a nuaber of papers written discussing 
Beo ductivity. Some discuss detarninants of programming 
productivity [Ref. 2], others provid2 tools (Ref. 4], which 
PME POTt tos improve productivity. Interestingly, few of 
these studies discuss or nake ref2rance to others who have 
discussed how +t0 actually measure this productivity. The 
philosophical approach foc many years was that programming 
Was an art. This made it virtually impossible to measure, 
fer it would be similar tS measuring the progress or produc- 
t8vity of a Picasso or Mishelangelo as he was painting or 
sculpting. Obviously, ther? 153 195 way to néasure the 
progress of art aside fron personal »pinion. This, however, 


3 
— 


in 


not acceptable in an iniustry bas2d on the profit motive. 
in the tate 1960's the tern "Software Engineering" was 
coined and with it cam? 32 number of ideas that served to 


puil pRegrawmang out of tha world of art and into the world 


or “<tve”y engineer, a wocLd wher2 naasurement is of vital 
importance. Software development was shown t> be an area 


that required discipline and a process-oriented approach 
PReti. 5S]. 

SOf{ware engineering has grown through the 1970's <t9 
——" bacome the rule for the management of programming. 
It has led to the deveiopmant of new strategies for software 
aa calitiersa. ent These strategies, top-down design, bottom-up 
deseer, Sst=euctwred prgraaming, moliular decomposition and 
metaprogranmming, bewe plrowaded. 2 better foundation from 


which software developers can attempt to meet the growing 


@emernad tcc software prodacts. Aithough these developmenz 
techniques have made software development easier and helpei 
He cone=+o! che cost growth, they have had little impact on 


productivity measurement. 
To Giscuss the measifcing of sodftware development or 
SriIgramm@_ng productivity, one must first determine what the 


pradtcz is. Peom theweiicst day of programming until the 





present, the predominant product sf discussion has been tha 
Piznme of code" (LOC). This is the product on which neacly 
all research and the database information are based. If one 
were a constrdction engineer ona would not discuss a 
building or bridce based on the number of bricks and girders 
used. Ptscead, foems 55 Floors of spans Wight be much more 
appropriate. These items are iategral but separately 
me2csureable components of the final product. So whi, 
Bhnetcrically, do researchers ani data base information 
collectors continue to insist on LIT neasures instead of an 
integral and separately measureable and meaningful component 
Ge s@e were 2nginsering? This not a question for this paper 
=O answer but one for th2 reader to consider when planning 
Mes OWF reseatch or data base sollestion. 

Ti rieet Waterial Support Offic (FMSO) is axperiencing 
ths same problems as the cast of the software indusrty. Te 
is faced with a huge damand for quality software from the 
Organizations it is taskei to support. (ae task2zng Of the 
Pes. Pive years is shown in Figure 1.1 below. These figures 
eusormmy LOr ehe Central D2sign Agenzy, the prinary mission 


or FASO. Ta figures show an increase in FMSO naintained 


(D 


S 


(D 


e 
Peogfe@s of 75.4% percent in this shor*t period. Bile: 
Peg@lre@s ere expected to continue t3 rise at a significant 
rate as the Navy csontinuss to automate more and more func- 
tons . another problem facing FMSO is the salaries of th? 
programmers. According t> Business Naek (Ref. 5] pregrammer 
salaries are rising at 3 rate of 15 percent annually and 
Saiaetes For top systems i1alysts cain reach $50,000 a year. 
This places an extreme burien on t22 personnel department td 
acjuire top personnel «hen hiring new programmers and 
ystems analysis. Ths DrOaue zi vst y Lssue becomes 
Wee Geer me y Clotical foc FHS) in the Light of the hiring 
freeze imposed during tha Carter administration and “h?2 
pres 


resent Reagan 


Grive +o reduce the cost of government in «he 


fds 
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CDA Program Growth 


FY 
77 MUXXEXXXX 5,389 


| 
| 
| 
| 
| 
78 XXXXXXXXXX XXX 6,420 | 
79 XXXXXXXXXXXXXXXXXX 7,722 | 
8O XXXXXXXXXX XXKXXXXXXXX 7,938 | 
81 XXXXXXXXX XXXXXXXXXXXX XXXXX 9,930 | 
82 XXXXXXXXXXXXXXXXXXXXKXXXXXXXXKXX 9,454 (April) | 

| 

| 
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Figure 1.1 FMSO Program Library Growth. 


This paper attempts to oresant a number of issues 
related to the measuring of progranmer productivity. ie 
Waid show that there are 2 other fastors that impact on how 
Ome interprets tne oroductivity figuras. The manager needs 
to realize there are sever2] differeat levels of the organi- 
zat on, omen WS its cwR prodwet cr set of products. 
Taetetore, each level nas a productivity rating for which it 
Must be responsible. In fact, the reader should note that 
tAS programmer is not the predominant link in the cutput of 


a programming project. The requirements of the Department 


O 


= Deferse and ccnscientious software developers throughout 
the industrv has placed increasing mportance on the rélia- 
bYOlLS@y era Haintaitmabality of softwars. This néw emohasis 
hes produced a whole arzay of cotresponding products which 
must be accounted for and new preductivity levels which must 


be examined. 


US, 
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II, WHOSE PRODUCT IS BEING MEASURED? 

Wher discussing productivity, befcere one can consider 
who to measure, one must first deternine what the product is 
and then who makes the product. Without a rational visuali- 
Beervom cr the product it is unintelligent +> discuss the 
@oidety of a person's, group's or machine's ability to 
deliver that product. Depending apon the level of tha 
Orjanization at which one looks there will be a variety of 
Geais, Objectives and products. Both Kiser [Ref. 7, p. 244] 
and the [EEE Workshop on Software Productivity (Ref. 8] 
address this impcrtant issue. 

Where the IEEE Workshop focus2d on the general area of 
productivity, Kiser was most concernad with software marnags- 
ment procuctivity. She focused on the idea that the manager 
Sevres Mas aS such to dowewith a programmer's productivity as 
does the programmer himseif or his t29ls. This is a nontri- 


vial issue. She lookzi at the top three leavels of 


1 
| 
| 
| 
| 


corp. goals <---> top agmt G--=— COmD. DE Od. 
preduct goals <---> niddle €--=-> product 
Peo jae goals <---> first lig2 <---> project 


task goals <---> programmer <---> task 


wy ee 
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Pigure 2.1 Kiser: Levels of Note in Software Productivity. 


management, shown in Figura 2.1 . Many managers have failed 
e 


tO Wnderstand why thelr fpeople, bsing well-trained and 





provided with excellent tools, continue to produce at unsa- 
tistactory levels. Orcs often, from this researcher's 
experience and the experience proviled by Kiser, the poor 
production levei is caused by higher level managerial poli- 
Gaes or actions. This can be understandable when one 
examines the concerns of tae various nanagement levels. 

At the corporate level, top management is usually 
Gemcerned with prorit maxigdization and market share. ENSG; 
being part of the public sector, do2s not have this parti- 
CUl_ar concetn but there ar2 comparable goals ( Figura 2.2 } 
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Figure 2.2 FASO Major MSission Areas. 


which are ‘flest suoport 3rd effective management of their 
Seproxd@ete $3.38 billzon, FY82, procurement authority. When 
On2 considers the impact of money management 322 this level 
recs undeescan@able “hat concerns For indiviual programmer 
Posa@uctetitses can get lost. [ihe “heer pretatiomwor top 
level management polices oy lower level managers can also 

ane SOt Produc TV Zty. 
he whe middie manayement level, Managers become 
Cencemnec Weth specific product dsvelcpment and rescurce 
pc ce sen. fOr Fuse, 22 Lets pram2ry Mission ac2a as a CDA, 
9 


Bemegemen<: is cencernsi with allocation of resources <t9 
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Figure 2.3 PMSO CDA Primary Product Areas. 


respective product areas 325 Shown in Figure 2.3 below. The 
@ilocation of the resourc2s is tamosred with the command 
goals and the budget proviied by th2> various sponsors 


The first iine level of managemeit, project management, 
+ 


is where one first encouaters the -_ of software produc- 


1G =,” She area with whish this pap2r is conterned. Here 
@he vreject @aneger is concerned w#ith meeting prescriped 
Milestcnes within budget. Tae products at this level are 
See vertous "“Aeligeraples", such as functional specifica- 


dss3omy ceS= plans, ¢tc., 

ate managed project with 

milestone requiremen<s. These asec Aehe products ene Must 
u 


B= against thei reresvective costs. 
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Memeeee 22n> deyel icsslf there are two groups, project 
teams and the individuals who make ap the teams. The team 
must be measured against its 2bility to deliver integrated 
software products. The individuais nust be measured against 
Basac ability to deliver specific portions sf the tean 
assignment. This is the point wheres programmer productivity 
1s discussed by most researchers. A special note is 
EGatiamed at this point. a@hile one usually assumes that the 
delivered products are 9f a specific quality, this seems to 
bé missed quite often when discussiag programmer products. 
The idea of quality in th2 product nust always be consid- 
ered. A person who can jeliver five programs in one day 
meet @re incorrect or do not provid consistent rasults is 
Met rneatiy 2S productive as one who delivers one product 
every five days but which is corract and easily maintained. 
Very few BEOm@UG TAaViEY measures take quality ales 


comsideration, as will be shown late2c. 


Hg 


BGter Fealiging ths variows prolucts made by diff 
Hepebee in =~he OGgGanizgation, one must than consider w 
Viewing thes= measures, management of labor. The views and 
concerns of each are usually quite different unless thers 
has been a considarable andunt of 2adacation on 2ach side. 


Management must understand there is an cverhead =xpense 


=o developing, Solleccing and ahalyzZzing productivity 
measures whic must be justified. EeUwce ely, one must 
have a set of neasures before one san determine constant, 
"normai"” or changing productivity. Also managenent needs 9 
know now i+ intends 9 use these neasures. Pac Weck 
Pets 8, Pp. SUA Sees Ectr Major uses fcr productivity 
S-scuee=- 4) woOtivatzon; 2) understanding; 3) evaluation; 


u 
anid 4) management. 
2 b= used for motivational 


oductivity measures can 0oO 
purpeses im three ways which proviie tangible benefit. 
v 


Pic Sty researchers [{R2f. 9,]) have shown that by paying 
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attention to a person or group, performance levels of that 
person or group will improve or chaage to what the observes 
perceives as 2xpected performance. This is known as the 
Hawthorne Effect. When managers tak= the time t9 do produc- 
migecty Studies the “Hawthorme Effest may occur, aibeit 
Lenporarily. Sceama 1s the ability to focus attention on 
desired behaviors, Eveneseaid Obgectes or products. The 
me2zsures selected will place relative importance on the 
ar2as being measured. Por instaace, if a series of 
Measures are selected whith include speed of production and 
Maintainability the perc2zived relation between them by the 
programmer will deterninrs which measure they emphasize. 
That perception of relative importance can have a profound 
effect on the final product. If programmers see speed being 
rewarded ot emphasized nore than maintainability, the 
ménager should expect to see prograns produced rapidly but 
mace daze hard to understand and hav2 little documentation. 


I= the reverse is perceivei, then the manager should expect 


ct 
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longer programming times with much easier to under- 
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and petter documented code. Miestheba MNotavatsag 
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they operate. Failure to develop a model will hinder 
managers in improving performance ani will kee software 
dewelopment an art instead of a’science. 

Titer d, productivity measures help managers evaluate 
perfcrmence because they quantify performance. It is easier 
te evaluate pericrmance over time within a single group or 
organization because the neasures retain constant. Nie Bek 
also very important t9 track performance sd that proper 
fescback to personnel can be proviiai. It is also important 
to.) 60oevaluate between groups to see how one stands against an 
medustey average. This h2s proven t> be particularly diffi- 
cuit ‘for software developers. Fev groups use the same 
measures. Those that us2 Similar sounding measures often 
fewe Sigriticantly differant definitions for the individual 
parts cf the measure. POS, wnewehne will be discussed later, 
2S a most common area of iisagreement. Nevertheless, it is 


stablish a baseline and 


(Dp 


important for sach organization to 
> bueea a database of information. PhisSs intormation can 
Gren be wsed for measuriazgy the avolution of nathodologies 
and technologies used in software ji2v2lopment. 

Fourth, oroductivity measurement imposes a managerial 
disecipi ane. Normally managers ar= concerned with tracking 
DEogimess against a schedule and buiget.The consistent use 
and taking of measurements can b2 extremely helpful in 
making projections of progr2ss against schedules and 
budgets. The manager must remember that a productivity 


measure is only a snapshot. It must be analyzed in relation 


+o its environment. In particular, managers aust realize 
the difference in the leacning curvis of various projects. 
A “fiscst-of-its-kind" project will have amuch differen* 


Werrrg curWe ‘than a simpl= modification t> a generic 
a Tae wEodmetivity races will normally chang= 


> jee 
BeapOLt=enetly to <he learning curves. 





The manager's need for measures and his goals can differ 
significantly from those of the workforce. Management often 
Wants to use the measures to identify exceptional perforn- 
mers or those who need adi2d training. 

The workforce, however, may view the measures as a way 
to generate either more preducts from the same work effort 
or tO generate the same namber of products from a reduced 
workforce. When the workforse sees the second side there 
can be severe implications, particularly if they are 
Gog anized. 

The workforce will rapidly wonier what their benefits 
will be from ali this new attention. Will the measures ieai 
tc more money for the sam2 hours, th2 same money for less 
hours for the good pecfotmmersS ani/or lost jobs for ths 
podzer ones? In an effort at job pr2sarvation, productivity 
may fali or stagnate at a predetermined level. This 
researcher has seen delibarats productivity stagnation by 
bricklayers, both in the housing ani steel industries, and 
by electricians working for a telephone company, all at well 
below reésonabie levels 2f capability. POE ome to think 
Siae Progra@mers and theic industry would not tend to act ia 
@ similar fashion is tt) approach this ar2a with ‘tunnel 
ya5 200. This may becom? a primary concern for FMSO where 

me of their government amployees asld specific GS ratings 
and incomes based on the number of personnel they manage. 
Conmand level management nust take scare in the intzoduction 
Seeeene  oLrOoducte wy MNGLTICS So "that personnel in theses SS 
Seeong> do not fel that ther jobs or ratings are in 
Meemeacdy 1 there is sizgaifisant iaszzase in productivity 
d ¢ 


mes to aMredWetven in foFc2e (RIF). 
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III. WHAT IS [THE PRODUCT? 
This researcher has ietermined that the predominant 
measure of programmer productivity is «the quantity of lines 
Be code written. This leads to savaral interesting conclu- 
sions. First, the programmer only #rites deliverable code. 
secord, the pregramper is the single dominant entity in 
software development. Ard third, there are no other rele- 
vant preducts or by-projiucts in 31 software development 
BaD jeCe. anyome «who has the opportunity to study or to 
work in the software development arena realizes the fallacy 
of these conclusions. Prszjrammers 4d> considerably more than 
Woate deliverable code. There are many other people 
involved, each adding important COUeES Outi ons oO the 
project. There are several equally important products. 

From the previous thaoter it was noted that there ars 
Many ievels of an Organiz2tion whose productivity shouid be 
measured. Those involved in software development realizes 
that various levels of £233 organization make contributions 
Bo the Farious products of each project. This chapter will 
Meaievae the diftfemen=z ofaduc<s that this researcher feels 
az2 relevan= to the measure of software development produc- 
PiG ty: Mis discussid2 will bezyin with middle level 
Managemen® and werk towards the individual. AS we progress 


own the organization t=h2 product will become easier to 


fs 


SEAS. The span of management control and resource respon- 
Sibilicties will dscreas=2. Thereforz=, one must remember to 


ensuze the product and tha level of the organization match. 


All too often people 2r2a evaluated on their ability <9 
Beoawiee 2 prodwet which they were 19% assigned to preduce 
Bememmeacgeaeny "Ole in producing. 


i. 





Onaec-Uneecely the reader will find in this section 
several terms that have multiple me2zaings. This is inesca- 
pable because there has been nO azcepted set of standard 
definitions within the software development industry. 


A. PROJECTS AS FRODUCTS 


[Mer e"CORcCEsc@en proj2st", generically, is a softwares 
development tasking for which an organization contracts 
another to produce. It nay consist of a nunber of sub- 
projects OL programs. An example is the development of an 
Operating system which insludes a job scheduler, process 


scheduler and file manager, Figure 3.1 shows the various 
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Figure 3.1 Software Development Products. 


Go@pomer= products of a pr. ject. PAS prOneece, ah Opera zing 


O 
system, must integrate zach of thse various parts to be 
if 


7 


complete. PHecetore, ta question of productivity here 


IO OF 
12 


Wheeher Or not the project can be d2livered on budget and 
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Eee he CoOnmeracted project is large, as in the operating 
System example, it will ba broken down into several smaller 
Peajects, Which I call “assigned projects" since there is 
little choice as to who will manage them once th2 contracted 
project -s accepted. The assigned projects will be given to 
severai project managers who will report tos the central 
contracted project manag2:. Th2 tole of each of theses 
project managers is +0 dzliver a fully complets integrated 
Opetaving product. 

The question at this point is, “Are these good items by 
Wwnich to measure productivity?". Yas, they are, for several 

e) 


reasons. First, for this level 


[mh 
1S 
Tow 


hagement they are tha 


only preaucts that are producei. Sarzond, the reason for the 


A @ | | oe] 


Manager to hold the particular job of project manager is for 
m 


na@/ner to deliver a project on tim>, within budget and to 
mae S@etstaction of the susto@er s> that the srganization 
may make its profit. What about the iifference in languages 
us2c or the sizes of various projects? These questions need 
Mo Gale theie crightrul plase in the data base of information 
@eetn.ec COCEpCrat2 on. Baca productivity measure has a set of 
Pat ameEters within which it can only be used. There is 3a 
definite need to know how capable a2 project manager 1s at: 


1) Gewelcping any project; 2) using 1 specific language; 3) 


fou 


MevetoOparg Various sized otojects; 4) developing machine 


devendert projects; 5) jeveloping Sse OCs] 2s-kKe a 
Pee jects; OF 6) m@odatying 2 generizc droject. 

Baenh or <hese parameters gives added insight to 3 
Peo ject Ba@nager's productivity ratin3. Pheweiss=, .ets one 
knoW how productive h2/she is relstive to all the other 
Project managers regardless of project specifics. Za Cho = 
sn other measures provide additional information on the 
Bebeti#te oroductivity of 2 project gminager within the diffe- 
rent parameters. Use 752 sel Or en -s=  OrOductLVity ratings 


he next higher lev2i of mnanaginent may improve both 


S 
het 
qt 
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levels of management's PEeduccive-y vrovided PZogec< 
managers are well matched to projects where ee 
Beoauctivity is highest. 


Be. MILESTONES AND MANASEMENT/SUPPORT 


At this point it may be advantageous to discuss 4 
Managemert tool that many may consiier to b2 or confuses 
wen. @ product. Peete i lo=sceone™ 15 1a point win the life of 4 
development project when a deliverable product, as listed in 
Pagare 3.1, should be comoletad. Many would think that the 
ability to meet project milestones shows great productivity. 
Bes WS not true. For if it were true, first the milestone 
MuSt, ihr fact, mean the productisi of a deliverable iten. 
Second, the deliverable item must 62 something of value to 
mie epeegect. If the deliverable 15, in fact, of significant 
value to the project then the production of that item is the 
basis for one's measure ani not the neeting of a milsstone. 


The meeting of the milestone shows only that the project is 


BPreecea-ng as planned. The milestd12 has no other inherent 
value. Phat =s,, one d92s not dsliver a milestone as one 
would a progran. The milastone is only another management 


Peo Sates Gs is a productivity measure. 

Bike milestones, Hanajy2ment/Support is not 3 product but 
a management tool. However, the typ2, quality and quantity 
of the  smepipo4r must be considered very carafully. 
Managemen=/support exacts 2 price in that it 15 an overhead 
expense. WES Ofelue 25 not 25 2 product but as. a tool. 
Heatly ail presentations discussing productivity refer <9 
the management/support tools. This is where the vendors and 
consultants mekea gr2zaz deal of anonsy. They speak of 


productivity improvement and the aids that provide it. 
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Mieee @re two parts ts this concept, Management tools 


aaa Support tools. The management side deals with systems 
that hslp predict costs and time sshedules and those that 
Srack the progress against the predictions and plans. At 


FMSO, this function is unijer the auspices of the Management 
Department, Code 92 {Bef. 10] where PAC-II is used to track 
ani DOD MICRO and SLIM ar2 used t> estimate software costs 
and time schedules. The values of this support can be very 
sub jective. Often the value of th2 management aid is that 
i= gives *he manager much more confidence in his/her deci- 
sions. The effec of the use of thease kinds of tools may 
also be scen on the ledger. If th2 systems help management, 
all else being equal, one would 2xpect to see fewer cost 
Ov2rruns and better personnel ma&nageanent. 

The support side has a @iriad of tools that predict 
sure-fire ways to improve productivity dramatically. These 
tools include various design procedures (i.e. structured, 
top-down, modular design), on-lin® programming and provision 
For each programmer t9 have his/h2r own CRI terminal to 
mention a few. 1.C. Jones [{Ref. 11] iiscusses nore of these 
tcols and their respective limitatiois. 

Tee fact that Nanagenent/suppor: is not a product does 
NOt @BIMiBize its importance. Oneseh> SoOpelarygs it Ls. vital 

eiftective software development. But the manager must 
realize that the addition of each oviece of management/ 

port costs meney for which aztrounting must be made. 
Although, there are many management/support systems which 
May improve productivity, the indiscrininate implementation 
@m tifewr use wall mot necessarily lead to productivity 
improvements. The use ani expansidna of nanagement/support 


Seren avea Wore hy of further study. 
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C. DESIGN AND FUNCTIONAL SPECIFICATIONS 


Design specifications are usually thought of as a 
peocguet cof the contracting organization. They are used as 
the basis trom which to make a contractual bid and to write 
the functional specifications. However, the design specifi- 
cations, as delivered, often must be rewritten by the 
contractcr in close conjunction with the contracting organi- 
@eeeon SO that they are explicit enough to properly writ? 
Pee fuPctional specifications. 

Both Keider (Ref. 12] and Howita [Ref. 13] discuss th2 
need for weil thought out and well written design specifica- 
elous . Keider's article, “Why Projects Fail", shows how 
poorly = projects waste money and resources. Howden's 
ert icile, ife-Cycle Software Valilation", discusses the 
ne2d for project design sp2ecificatiov1s to meet five proper- 
me's. Picct, the spesifiscations must b2 consistent 
internaliy as well asin any related documents or other 


=he project. Second, th= specifications must be 


th 


PertloOens oO 
compiete. They must b2 2xamined f2r missing 292 incomplete 
information requirements and to ensure data properti2s ars 
anc haradec. Toe, the ssecifications should only includes 
£Y items without reiundancy (not to be confused with 


Gwndaiicy to s1sure reliability). FOus. 1; 7) 21S 


cf 
© & a 
@ 


feasible with 2xisting technology and hard- 
@ @eeen, the sp2citicatioris must use correct math 
formuleas and decision tables. 
eeadmee Should cr2acognize that the validation of 
Siew Cec ors and Eunctiznal specifications is a 
© 'Pask. The systems analysts who validate the 


Beet ons ane who writ] and validate the func- 


(v 


‘2 
pec. fications must be held accountable for their 


L 
resource us2 in the production of these products, The 
di sarefully, 32S discussed 


specifications need *0 be examine 





above, especially when done consiiers that approximately 
forty percent of a projects resources are used in the design 
phase {Ref. 37]. Peer yuwelity here is very difficult and 
costly to try to overcone later in the software development 
cycle. 


D. LINES OF CODE AS A PRODUCE 


The line-of-code (LOC) Toe Diet ans the predominant 
measure used throughout industry to liscuss program size and 
Productivity ratings for all levels 29f software development. 
Interestingly, “hough th2 entire industry us2s LOC as 43 
measure cf product definition, ‘f2w agree as t> what a LOC 
i gi One of the first questions asked is, "Do you mean 2 
Haae of cbject ccde or source cod2?", The industry has had 
sone success in distinguishing between them but not in 
choosing one or the other as 2 universal measure. Source 
cole is that written by th2 programner while object cod¢ is 
*h2 compiled code stor2d in anemory. Source code is mnor2 
ofter used to describe programmer productivity than object 


Gees wheach is usuallv usedyto define the gquantity of 


computer memory reguir2i to Store the orogram code 
[Reft. 14}. 

Assuming one has settied on sourst2 code as a part of the 
measure, what determines a iliins of code? Some have said 
Gath line or statement written bv the programmer regardless 
of length. Others try to force thea line to have eighty 
Gaeta gacte=zs. Sf2ei Others try £5 define i: by statement 

D 


Peace Werton characters by iangquage (i.¢é. peériois in COBOL or 
se@icolors in PASCAL). 

enas weren't bad snough, he Teme Guestson “2s, 
Ge @ae lines are "sSduntabis??". That is, some want 
erentiate between axecutabise statements, data decia- 


Ss, comments, nondeliverabie debugging or testing aids, 
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SIC. Use of LOC eéach of these areas must ba axplicitly 
defined because studies have shown line count variations of 
more than two-to-one on tha same vrojram [Ref. 15]. 

After the LOC is weli defined ani published, one must 
watch carefully because, just as tha measure helps manage- 
ment to rate personnel, sd does it haip personnel to promot: 
themselves, often by manipulating tha rules in their favor. 
Here are several examples. Ine company settied on every 
ijine written regardless of length. After some examination 
Of seWeral programs, lines were found not to be complete 
St2tements nor eighty chacacters in Length, thus padding the 
true productvity levels. Another may decide to use eighty 
characters as the defined Line. In this case it would not 
be unusual to find variables with 2xtremely long names or 
us: of the "blank" character to fill up lines and thus padi 
the productivity rating. Paradoxically, the programmers may 
me senced <> have larg= numbers sf blank characters if 
Managemert requires the us2 of structured programming teéech- 
nigues. Another problam is that programmers nay fight zhe 
use oz higher level languages so they may program in a 
language in which they ar2 comfortanle and which requires 
more lines to accomplish the same task. Jon2s [Ref. 1 
p.31-43}] discusses the LIC measurs more axtensively th 
presented here. 

Since the measure is so difficuit to define and may lead 
20 unacceptabie programaiag practices, as stated above, or 
Gaise@ De=adoxical conciusions, as iiscussed in tha following 


Che-pter, eius regearch>c f2e15s LIC iS a op 


s-~ OO Ww fa wp 


ene | shale ties 
measure. Yowever, this ioes not mean to say that there is 
mo use for LOC as a produst measur2. In fact it is the only 
> 


méasure avaiiable when one is performing maintenance D 


ju 


programs which entails cshanging individuai lines in 


program. Therfore, we must have a2 i2finition f9r a LOC. 


Z> 








There are many different languages in which one can 
program. Since each has its own rules of construction the 
definition of a LOC will necessarily be different for each 
language. This researcher prefers t> view a lina of code in 
the context of a complete sentenc2 or phrase of spoken 
language. fach programming languag> has a defined equiva- 
lent of a complete statement or phrase. Just as Hemingway 
and Faulkner had different styles of conveying information, 


so wili programmers. This is not a latriment to programming 


iy 


ee MOre than it is t9 writing. Programmers will settle 
geo Scenmdard line lengths with whith each is comfor<able. 
AS long as management is satisfied that the style fits well 
santo the structure of the lanyuage then there should be no 
problem. This does require manag2meant to supervise and to 
Pro2n those that are not consistent in their own programming 
Or are far from the “average” line length of the rest of ths 
programmers. 

The countable lines should be those that are vital to 
the program quality and specific language. The lines that 
ac2 niceties but which aii in th2 raadability of programs 
have geod reason to be in programs. They should be courted 
mic Moc wien fudl credit. The comment line is an example. 
It is necessary for rsadability bat a one hundred line 
Drogtem does not need an i2idditidnal hundred lines of 
comments. Contrarty to others, t11s researcher believes 
sone credit should be given for comment lines. HOWEVErL, TO 
keep verbosity out of programs due £39 comment lines and t9 
be consistent with the creiit jJiven for reused code 
fame. 26), they showid only count 2S twenty percent and tnen 
BProumo pe “a full ewgnty characters long. Lines that are 
execwtabie or data deciarations ieee Lake: sheuld p> 


Gourced Sully 2s one lane 





ser 


me ec is used as a measure for program length, ah 
Smead pe Weasureld as a block of LIC, haing at least one 
hundred lines ard not mire than one thousand lines per 
Biosck. There are two reasons to d> this. Pirst, each block 
or LOC can have a time valu2 association. This allows 
deveiopers to speak in terms of tine per block of code. 
This is valuable when trying to estimate the time required 
to develop a program estimated to b2 some number of blocks 
S- code long. second, cole must have an intrinsic quality. 


It makes little sense to iiscuss 2n2 tested, debugged and 


documented LOC. But it joes make sense to discuss a biock 
of code with the same qualities. This tends to force «hs 
cole to have some mininun level of quality. The quality 


Tesguirement takes into consideration the time spent by the 
programmer in writing non-ielivered test code and debugging 
fags ied in correcting logic errors. When LOS are reused 
ee Count Value should b2 a percentage of one original LOC. 
Basili and Freberger [Ref. 16] use twenty percent in their 
research. This researcher recommenis starting with twenty 
Bere@ep- and then adjusting it according to the percentage of 
tine required to locate rayusable cole instead of developing 


Sstogenal code. 


E- MODULE AS PRODUCTS 


A module is a single, intellactuaily managable portion 
OZ 2 progran which is seo0arately conpilable but which must 


VE connections to other nodtles. lis *seze is Variable but 


fp 


n 


ontains only one complate responsibility assignment of 32 


he 
ct 
Q 


ie) 


Pogeams It has only one 2ntry point 2nd one exit point and 


Q 


conforms to the permitted logic structures of structured 
programming. The responsibility assignments are determined 
3 @é any work on individual 


G@r in =h design phas3 bet 
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mcities is begun. One of the key ar2as of modular design is 
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the selection of module contents bassi on the probability of 
change during the maintenance phase. In other words, assign 
those pertions of programs/projacts that are likely to 
change due to hardware or technology to their own respective 
modules. The advantage gained by this bit of overhead is 
found in the cost avoidance which follows during the mainte- 
haace stage, where up to seventy percent of a project's 
Sests lie. 

There is a paradox concerning maintenance and well 
written code. MeeeGne GPCdcutcs pESaucCtiVity during» the 
mMaintenernce phase by cost per defest, a popular method, 
he/she will find that very poorly written code has a lower 
@ese Per detect than well written coi2. This occurs because 
poorly written code has many 2rrors which programmers must 
Seema Buch time correcting. They, therefore, become very 
Familiar with the progran. The initial costs of relearning 
the pregram logic are spread over nany errors in poorly 
written code, and over very few errors in well written code. 
However, the totai cost sf maintaining well written code is 
usually much lower. If one were to take the same well 
written modular code and compare it *9 the same well written 
noo-moduiar code one should find: 1) fewer Logic errors 
because of the extensive analysis during the design phase; 
Oy 278®> CGasiser.to locat2 errors since they can often be 
traced to one module or at least t5 2 branch of the progran; 
3) it's easier t> relearn the logic because 9f the need t9 
only learn one or afew moiules instead of the entire 
pr2gran. [eran es OC ail SE wene se points are realized, FMSO 
couid save a great deal in rescurces and improve customer 
Satisfaction. Since FMS) presently nust maintain over 9400 
Pesgse@S and respond ts »sver 320) Srogram trouble reports 
(PTR) aPnwally, any reduction in th2 cost, in time or money, 
eeeamper 2 -eWsDaSisS COUlii lead ts significant savings and 
higher Produstivit y ratings f9r program maintenance 

on 


peel. 


= 
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The use of modular programming allows +wo other areas to 
be explored. The first is Parnast [Ref. 17] idea of progran 
fanailies. mie ded iS t> Took at similarities in programs 
before i0o0king at thair differenzsss and write generic 
programs based on the sinilarities. Then one adds the 
moiules that will make the programs individualistic. ial 
this way programmers can reus2? existing code which is well 
tested and with which programmers are thoroughly familiar. 
This helps to reduce initial projest development time and 
costs and to reduc? maintenance costs. 

ame Seconda area is that which Zoll (Ref. 18 , p. 51] 
refers to as "metaprogramming". This is the use of data 
base libraries of modular code to build complete prograns. 
The code is generic and the metaprosgjrammer merely researchs 
*h2 data base and selects thos@ modules which will neet the 
Bro gGmeW iogic. In this way progcanmers write much less 
S=ugimel code. DoanMerdaneamnd Poyaton —f Ret. 19] report that 
at Raytheon Company some nw applications software have been 
Geveliopec forty times faster than by uSing traditional 
development methods. Re1ised modul2as have been averaging 
between forty and sixty percent of tha total LOC on major 
projects. PAS DPEODewLILty s£ inducing logic errors is 
reduced significantly and the probability of taxtual errors 
is also reduced due +o the reduced amount of original code 
required. Kendall and Lanb [Ref. 20], in their research at 
IBM, have creported data which shows that metaprogramming 
from a data base of modul2s should b2 seriously considered. 
Phei= study showed that 2ighty percent of the applications 
programming effort goes into production of programs whos? 
used life is less than 3ighteen andaths. Therefore, any 
reduction in «he effort t9 develop these programs and any 
Beaer:om in the maintenance effort sf *hese programs will 
Baove@d= a teceor of four inereas? in the savings to be 
applied to the maintenance of the twanty vercent portion of 


2aemuce Cycle, 


ct 
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“he programs with a Siginftican 
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The added attraction of modular code is the idee of 
completeness of the task. For a quality module to be deliv- 
ered for integration it must ba: 1) documented: 2) coded in 
Bes GMttrety; 3) tested; and 4) debugged. These are much 
more difficult tc attain with LOC as the product. In parti- 
cular, it is very difficult to tsst a block of LOC since it 


relies heavily on the ramainder of the code, Therefore, i 


ct 


(D 


can only be examined by inspection while modules carn »b 
snspected and machine dabijyged to a near zero defect condi- 


Beon pricr to integration. Aiehouga che docimentat son): 


VU) 


not vitai for module delivery, it can be and should be an 
organizational requirement. 
The idea of designing projects, especially large ones, 
by dividing them into subprograms or modules is a very o13 
concept in programming. During the 1970's it became a topic 
St hagn =ntsrest as a Way to tmprove program reliability and 
Meaintainablility. ROss stmal (Rebs 20), Liskov { Ret. 22], 
rossman {Ref. 23], and Parnas _Ref. 24] [Ref. 17] wrote 
formidabdie papers extolliag the virtues of modular progran- 
ming. Yer there are many softwares development organizations 
mec Go not urderstand ta2 ‘tera, 1s2@ or value of nodular 
prod grefiming. The Department of Defense (DOD) appears to ba 
On? Organization that does not fully understand the value of 
mOiularization and reusiijg code. funson fReE. 25) points 
es CEt in his short paper OM raducing software costs by 
reusing code. Dlishofft fRef. 26] obsarved this problem at 
Mae Gemeral dotcrs Research Lab where modularization not 
Only appeared foreign to anaiysts and progranmnars but was 
viswed as Getrimental t5 the software life cycle. The 
unfamiiiarit With modularity is also ovpresent at the US 
Navy's Fleet Numerical and Jceansgraphic Center in some 
anaivsts and programmers While this does not appear to be 


@4 oroblem e+ FPHSO at the present, internal training may ba 


rejyuired pbecausé Of “Sienover of software aesvelopment 
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Paes Section concerns quality aodules. These are 
moiules that are coded in their entirety, tested, debugged, 
and documented. Each organization will have ts set up the 
requirements for a countable modula. This researcher recon- 
mends these attributes. They ansure attainment of the 
organization's minimum quality standards and take into 
consideration the programmer's time in debugging and testing 
tha module. When reused nodules ars a part of the delivered 
prodauct they should be counted as a percentage of one 
moiule. Basili (Ref. 15] used twenty percent in his 
research. mite WEP a goed starting péint. Butt ens 
G@rgemizetion finds that this is not an accurate percentage 
or the time required to dévelop original modules then the 
percentage should be adjusted accordingly. 


PR. USER FUACTIONS AS PRODUCTS 


The previous section deait with functions based on 
Desigeak structure. This section deals with functions based 
ch user requirements. While modules may vary in length by 
approximately one hundr2d lines of code, user functions can 
ety Wp to several prograns. An 2xanple of this is a singla 
entry accounting systen. A company may want 2 system which 
performs several functioas such as: ledger maintenance, 
SevOeCahaq, file maintenans>, weekly reporting, ztc. Each of 


Teese Smerations or functions, is 32 deliverable product t9 


or 


Customer as a part of the single entry accounting 


() 


peckage. The quality of the entire sackagée is Jatermined by 
Phe ciWsto@er satisfaction with #2ash individual function. 
Albrecht, [Ref. 27] cr IBM Corporation, uses this measure as 
ehe primary Beans of determining productivity ratings in the 
Applications Development Sroup. H2 points out that one must 
be careful when uSing this measur? 2fF any other measure by 
xe2oing the major project objectives in perspective: aye 


ime, within budget, and 2 satisfied customer. 


31 





The specific product neasure is what Albrecht calls 3 
function value. The approach to determine the function 
vaiue is to count the number of external user inputs, ingui- 
ries, outputs and master files that the project must develop 
aS a part of the user requirements. An external user input 
is a communication from the user => the computer such as 
data forms, terminal scresas, keyboard transactions, optical 
scanner forms and the like. Thess do not include inputs 
from tapes and data sets, which ars considered as internal 
Opa Pars Of the file count. Each of these user functicns is 
weighted by a value designed t> ceflect that function's 
value to the customer. Appendix I shows the details of 
determining the function valu@ and Appendix II shows <th2 
detaiis of determining the sizing and complaxity of an 
entire project using function value somponents. Appendix II 
uses the same external us2rc inputs and some internal inputs 
as comporments +9 comput) ths function points but also 
provides for the the computation of 3 developmant time esti- 
mation. i. eS ahpertaat tomot> that Chrysler [Ref. 2] 
Saawecd ia an unrelated and indepeadent study that tkese 
components were most Significant in predicting development 
tine. 

Albrecht's Zunction value concept has several advantages 


Ov]2r those ne 


ry 


assures previoasly mentioned. First ,gase,, LSmehe 
only measure that deals sp2cifically and directly with user 
SetiosGachion. The other neasures virtually ignore the user 
between the functional specification phase and the implemen- 
tation phase. iy2s Method cormstantly works with the user. 
Secondly, Since its focis 1S on us528r requirenents and not 
Somceiig@eimg lanes or blocks cf cod or modules, it ténds <9 


EmPe program@mer gaming to improv: his/her productivity 
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nq @z@igicially. Thicd, the neasure breaks the project 
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user defined portions of importance. This focuses <=h2 
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Crt towardS teamwork since it reguires the development 
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group tO work asa team toward the production of functions 
to which the user has placed a well defined importance. 
Lastly, the method provides more opoosrtunity for 2 smoother 
evolution of change than the others. Tt focuses attention 
On the cost of each function and the effects on cost of 
mii-development changes. The sonstait attention to cost and 
user involvement provides a better azetchanism to control the 
change process during development. Tt snables the planner 
to design for changes that may occur during the life cycle 
eee my not te cost 2ffective to include during the 
development phase. 

The function valus soncept has three disadvantages. 
First, there may some guestion as to whether to call a 
component an inquiry or an input. These are not always 
distinct items. Mme-e2h> weighting Tactors a@re different “géor 
each this may Significantly alee the final function value. 
Second, users play a larg2= part in d2termining the weighting 
BeSctersS, as it showld bea. Gsers can be fickle, therefore, 
Be @s Cfteneextremely dirtficult to gat them to admit "+ruth- 
Pu ty* wheat they desire most. ie 825 hot, sommuch that they 

Ging information but that they don'+ really know what 
thay want. Therefore, it requires talented interviewers and 
ers to determine th2 true desires of the users. The 


isadvanztage is that this measure is 380 good that 


w Ar 


May tend to rely on it t90 heavily. Thies iS pot 
ate or universai neasure but it is a good one. The 
Seesines can gere insights 22 products and produc- 
at this measure can not. The function value is an 


asure and must be used 2s such. As Stevens 
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Ref. 28} of Performanc2 Management Associates Inc. af 
Gaimtsdaie (Nz) »po@nts out, there is no undversal measure 
et. We must use all the imperfect nsasurées available in an 


Seome =c Gescribe the proyjtamming activity. 





G. TESTING, INTEGRATION, AND IMPLEMENTATION 


One of the concerns of managers, when discussing 
programmer productivity, is how to iacorporate non-delivered 
Geae in the calculation of productivity. The non-delivered 
Seas consists of test coi:, debugjing aids and incorrect 
Googe. The incorrect cod2 is a function of ths programmer's 
skill and is a penalty to his/her productivity rating. The 
test code and debugging aids are not mistakes. They are 
used by skilled programmers t5 ensare coding quality anda 
ceerectress. There has been s2me concern tha= weene 
programmer should have this code included with the delivered 
Seas fOr pmeoductivity calculations. This researcher does 
mot concur that the test sode and debugging aids should be 
included. The programm2ects job is to deliver code that 
mezts the specifications. The only way to ensure the codes 
actueily meets those specifications is to perform some type 
Of test. Test code ani debugging aids are tools of the 
programmers just as milestones and management/support are 
todls for others in the software iav2leopment arena. They 


are @ necessary overhead a#hich programmers must employ if 


thay are +o deliver the quality products discussed 
pr2viousiy. 
The integration, esting and implementation pkase of 


software development utilizes approxinately forty percent of 
he prEojec='s resources [R2f. 37 ,p.18}. Intultively, on2 
would think that an area which uses 359 much of the resources 
would be a prime place to do some productivity tesearch. 
Thess, wWRteortvunately, iS not thse case. One of the prime 


reascns nas been the inability of tha industry to determines 


the role these activities play. Sal CcMerGally, there <.s 4 
question @s towwhether testing is 2 dart of dev2lopment or 32 
parz of quality assurance. ££ st. 15 pas of Jualicy <ssue 


Somes 2 aen it Zs an cverhaad and not a productivity concern. 


t 
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If it is a part of development thei the product is tested 
ani acceptable code. But what detecnines how productive the 
testing is? The time expended in testing does not help to 
Geeer eine the productivity of testing because the time usei 
an testing is a function of the tast plan and the number of 
defects found. Defects found does help to determine produc- 
tivity. It shows either poor design, poor programming, poor 
quality assurance practic2s or any combination thereof. 


Integration is left with the same type of problems. 


Mis aGCtivity takes projest portions, nodules, LOG OF 
programs, and brings thea togetner to form a cohesive and 
integrated product. But if there are major iifficulties 


ersourtered are they the the fault of the integrators? 
Probably not. The fault probably lits with the designers or 
the programmers. 

The manager must be aware of th> problems that develop 
during this phase and k¢eo0 recsords sf then. Though there 
were He conciwsive reports found on how to deal with the 
Peeot@ation, the consensus from the literatur? is that it 
Mase hept Pm a2 data base (Cor later study and consideration. 
Th2 science of software isvelopment has net progressed far 
enough +o completely handl2 the test, integration and imple- 
mentation problen. Most researchers are of the belief that 
££ we get control of the jiavelopment process in a scientific 


way these problem areas may disapp2ac. 


H. DOCUMENTATION 


Mme poiwacy welief in the induscty and particularly in 
PomeUcmeract softwere develspment projects have two separate 
products: program code ani program idcumentation. THES: Us 
an extremely shert-sight21 but understandable belief. As 
leng as software development is viewed as having two 


Bagemtcts, chs belief pr2sents the opportunity to discard 
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one. Since the frogram is what is wanted, all too often the 
documentation is reducei ia an attamot to reduce development 
costs. The view that there are twos products and the prac- 
tise of reducing the docunantation tarive on the belief that 
software development and softwar2 Maintenance are not 
related. This is not true. The documentation is required 
eo reerh the progra® logis and coding structur2. <A software 
project that was poorly dssigned and poorly or not 

Socu@ented is extremely iifficult ani much mor2 costly to 
Maintain than one that was well designed andi well docu- 
mented. Nearly every other industry (i.e. automobile, 
Slse2ronics, @achine tools, etc.) that produces a complex 
product provides documentation on t12 logic and design of 
that product so that maintenance personnel can provides 
quality and cost effective maintenance. Ther2 1S no reason 
to believe that the software develooment industry should be 
ema different. 

This researcher beliaves that documentation is not a 
separate product but an integral pact of all well developed 
SQLtMare projects. This chapter consistently discussei 
fuily coded, well documented guality software. It should ba 
intuitively cbvious that 32 program that does not operates 
Peoweeey 15 Of Little or 195 value. And that one that oper- 
Me-smoremertiy but is dirricult +t2 inderstand and maintain 
because cf voor documentation is of nuch less value than ons 
mark Superior documentation. fhus, the documentation has no 
Sp2aci fic measure of length only ons of quality. ie) os 3 


and quality assurance experts <9 


EF 


Probiem for the developer 
ensure chat the document2tion is provided and adequate ina 
B-aeeaperg 2£2e crogram lozyic and coding structure of <the 


acl ject. 





During the research for this paper it was noted that 
there is a great deal of nisunderstaading both in the liter- 
ature and in the industry about programming and software 
development productivity. The misuiderstanding lies in the 
ar2=a that, When questioned about the product that is 
Beoauceeé, one Will receives guizzical looks or long spells of 
Silence. People immediately want t> jump to discussions on 
compiexity, language, tools or the jisvelopment anvirorment. 
Wiese “heve ilittls to dd with calculating productivity. 


Their roles are as parameters withia which one must analyze 


mae sopecitiic productivity rating. [Neo aS fot co. Dela s ers 
tha importance of thes? 2reas. It is simply a matter of 
G@ejganazarg one's thoughts. One can not antelligently speak 


Of S8proving productivity intil one first has a quantitative 
measure and secondly a jiessription of the environment. sieye 
often people in the iadustry look at the environment not 
Onl® EzESE but exclusively. Bmenout 4 p~PpEOdust d2=finition 
and the méasur2, the environment cannot be understood. 
Productivity has two components: OULpUtS And inpucs. 
THe OWUtputs, tLtocsely d=fined, acre th2 products previcusly 
@scomeced: projects, projrams, functions points, modules, 
amma «=LOC. Dey ers depenieant on th= corporate hicrarchical 
levei ané the philosophy ased for software devslopmen*t. Ths 


Boots Very considerabiy depending upon which productivity 


Measure one is interestel. The most common input used is 
“h2 person-month, 160-175 hours. [This can b2 broken down 
WeO 1S wearious parts by programmecs, managemesnt/suppor?, 


a 

S¥s*e@s analysts, and program analysts. But there are other 
Simeesetre. @27 be worth consideriag such as CPU time or 
terminal connect time. Though, th2zs2 are rarely if ever, 


Cnsiaerzed. 
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A. LOC PER PROG RAM MER-MONTI H 


The most common measure used for assessing productivity 
throughout the industry is LOC per programmer-month. Though 
avery popular measure, it is not vary geod. Sel)s (once otha! Gh 
besed on LOC it is subject to the Line counting variations 
menzioned in the previous chapter. This variation can be 
dimited, .to a certain axtent, by setting organizational 
Standards as tecamendei earlier. This would permit consis- 
emery | an che Organization but not across the industry. 
Recail, one of the reasons for measuring is to make compari- 
sons across organization2l lines. As long as there ars 
Waciations in the definitions of components no intelligent 
compérisons can be made. 

b@G Per progra&@mer-monoth is ineffective for noncoding 
tasks. The tendency when computing this measure is to use 
programmer-month as the total d2velopment time which 

Sluaes these nonccding tasks of i2sign, documentation, 


sesting and management/support. Sint2 no coding is going on 


Meing these ao >= it naxkes little sanse to include them in 
ene coding efror*. Therefore, that would imply that this 
measure should be used only for th2 coding phase. Of 
colrse, “hat iccuses attantion on the coding task exclu- 


vely, which is a miLaoimnal portion of the software 
development srttort. 

Finally, this measure tends «£5 penaliz= high-order 
laaguage (HOL) programs in Eavor JE programs written in 
Assembier ianguage. Jones (Ref. 29, De 2t) Pprovacedy=is 
exampie shown in Pigur2 4.1. This is an example of the 
Sa@e program written in two difrerant laguages. Two of the 


purposes of using HOL are to cut costs and improve produc- 


taeacy. put the example shows the paradox of this measure. 
T= appears that Assembler language is more productive *han 
he HOL even though the dL program took one asnth less to 
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| 
| 
Activity Assembler 
| 


agp emo => SSeS eo Ee eee oh 





Language 
Design 4 weeks — 
Coding ‘4 
Post Ing ; 4 
Documentation 2 
Mgmt/Support 2 
| Retal Badort 15 weeks | 
| (4 months) | 
Lines of code 2) 00 | 
{ 
| LOC per prog- fon 5 00 | 
4 { 





Pigure 4.1 Assembler Lanjuage vs HOL. 


produce. Notice also that Jones us2d the term "programmer- 
ronth" to mean the entire program development time, a common 
Boeceico, aS mentioned earlier. The actual programming 
tines were one month ani one-half month for Assembler 
language and HOL, respectively. Ev2n if this time frame is 
used, though, the Aassembier language at 2000 LOC per 
programmer-month appears to b2 twice as productive as che 
mem a= VOOO LOC per programmer-monto. ies DOLnesS OUT en= 
Paomwmee Of NOt Being consistent abdut terms. Jones uses 
proqrammer-month +> mean the antir2 davelopment time which 
Yeeudead an average productivity figure which included 3 
period when no ceding was being done at all. Using the tern 


= 


Stmeeoctily and comparin it to Jones! usage leaves us with 3 


oO 


tome tO Ore dirtterence im PprogWeesvety f£5r Assembler 
S 


Benomlese Sid < six to one difference in productivity for ths 


HOL. 





Be. MODULES PER MONTH 


This particular méasure was prsserted in a paper by 
Crossman (Ref. 23]. Surprisingly, tais researcher could not 
find any other references that have attempted to duplicate 
hes findings. Yet he pointed to several advantages which 
this measure and its mathodology of program development 
Sup pOEt. 

Moduiar design programming tends to minimize the 
Smieekinty Ce prejects. Winimizing the complexity parameter 
allows the manager to reduse the number of varizbles he must 
Goneéider when waking prodactivity scoaparisons. The defini- 
tion of a module appears to be mor2 consistent throughout 
mieustsy than LOC which gives it a potentially much better 
comparative capability between orgaiizations, provided th: 
ether organizations use this measure. The use of modules as 
a product provides a consistency throughout the development 
cyctie. Bt @hcitig@es the design, coding, testing, docu- 
menting, and management/sup port phases. Yet it can also be 
Pees@e Gown 2rto its irdividual component efforts to deter- 
Mine which effort has tha graatest impact on development 
tige and the impact of 2ach moduls on the project as 3 


whole. 


C. FUNCTION POINT DELIVERED PER WORK HOUR 


Albrecht {Ref. 27] discussed th= 3sffects this approach 
nas on showing the relative productivities between 
languages, voroject size and various programming technoio- 
gies. The methcd focus2s on the external attributes of 3 
program and the work-hoirs contributed by both IBM and 
customer personnel assigned to work on the project. lias 
covers all phases of the project. The goal of this method 
of measurenent is to state develonpmeizt costs in terms of «he 


work-hours used to design, program ani test *he applications 
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peo ject. Althcugh ther2 is not enough data available 
pr2sently to give conclusive results, the report does indi- 
cate the capability to show the relative productivities of 
different languages and develcpment technologies. This is a 
major advantage that is not possibl= with LOC and has not 
yet been explored using moiules. 


D. SELECTED INDUSTRY METHODS FOR MEASURING PRODUCTIVITY 


the preceding sections of this chapter discussed various 
methods used in research to study »orogrammer productivity. 
Bash method mentioned us3s a ratid of outputs (project, 
Paegrem, specifications, addul2s, LOI or function value) to 
nputs (person-months, prdgranmer-nonths, Or work~-hours). 
Previous sections proviied recomnended définitions for 
selected output and input components. This section presents 
measures used by several prominant corporations that develop 


scfttware. 


1. Bea 
Measurement of progrios is stili a fairly Sees 
Drocess. WS can measur2 size, based on tlines of code! 
- ‘'ruwoer. Of St catments', ees ceeptance Of <ehese 
measures is rot universal. “Acceptance Of lines of code, 
AS _ an example, seems to be based on the view that 
2ithcuch lines of cod? aay be an imprecise measure, it 
2s sométhing that can ba @enumeratei, and until something 
Merce == discovered ws wiil continue to use it. There 
is a veiled invitation here to find somethiag better. 
| Ref. 30 Pe 372 
This is the philosophy uséd <+*o approach «he 
@e2surinc of pregrammis activities at the Santa Teresa 
Laboratory of IBM. The "Something batter" that IBM has been 


Mareagqusco crefive fom the last thre2 t9 four years has been 
the software science metrics leveloped oy Halstead 
Lae ee 3 ij. Figure 4.2 shows the major elements in use by 
I32M (Ref. 32] [ Ref. 30]. The phiisssohy for using software 


4 7 

















= a a ee eee eee | 


Operands = lues that 2re changei or used as a 
1 


va 
Cemepencs £2° change (sonstants, variables 
Operators = elements that operate on or with operands 
(epeudelon 5odes, dslifliters, puactuation, 
arithmetic symbols, branches (DO WHILE, 
IF THEN, IF THEN ELSE) } 


7), = humber of unique operators used 
"Np 


N= number cf times the operators are used 


humber of unique »dperands usei 


ct 
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N5= number of s the operands are used 


Vocabulary (7)) um of unique operands and 
tors used ln the progran.. 

a measure of the repertoire 

ments a programmer us2s to 

ere a DEOJranl. 


OHO ct 

Bticto > 
WD (D 

t(D 14-04 

(D FU) WU) 


oO 


7) 


Length (N) = the sum of ths baa cs usage and the 
Operand usagé. t LS a measure of 
progran size. 


Ny + av, 


a Meisure of the diftficuity of 


Womtand COdemsna, aim pultively, a 
measure or eas? of reading. 
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Figure 4.2 Halst2ad B@lemant Relationships. 
Selerocemm&et™>i.cs is built on the following beliefs. Le Si, 
e 9 


©) 
=n any given language, one *y £ program is no harder to 


Gone Dnam another. The 2x perience at Santa Teresa labora- 
Sory over the last five years is that the only things that 
rect productivity are the languay® and the tools used. 


& a 
They have found that HOL is 2b 


out twice aS productive 3s 
anguage. Secoiri, asidé from language, the 
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development tools are what affects orogrammer productivity. 


To this end, IBM has consistently adjied to the "workbench" 
fo) 


rh 


their programmers. TaAey have provided on-line program 
Ming capabilities, given each 9rogrammer his/her own 
@ebGimeal in his/her office, proviied a dedicated progran 
development computer and various programming aids such as 
Ser pt. iiasd;, tmerderinition of operators anid operands,is 
consistent across languag2 barriers. This gives software 
Science metrics a significant advantage over other measures. 
Adiiticnaliy, IBM research has shown that the size metrics 
used by Halstead are as accurate as LOC for measuring 
program size. 

Since programming productivity is believed to be 
constant for all programmers, given the same environment, 
T3M has looked primarily at tha Batizcuisey metric. 
Difficulty is defined as 3 metric that expresses the diffi- 
MaeeyMori#rsateng co€e. Ft takes int consideration decision 
noies, the repertoire of dperators used and how concise the 
usage of the variables is. The measure, then, also appears 
+o be one for ease Of reaiing. Puelos omoc tell how diftii= 
culc the program must be. Tt Sonly'tells How difficult the 
programmer nade the program. Hieagh i pneiouicyecanwecns fron 
BGO 2 prodsaammang skilis, poor program Structure, inexperi- 


ence with the language or the compizxity of the algorithn. 


mee Meme of thesssmesric is three fold. ft tends to indi- 
cate errcr-proneness much eazlier in the development cycle 
than traditional methods. heed eiyetay., “ene More J2fticult 
cme EFCGram, =he more aredr-prone it ils. The measure can 


oniy be taken afzer coding has ben completed but it can be 

calculated immediately following ths first clean compile. 
There is no need to wait for testing. Seconagly, it “po ™res 
Ci <mese programs which need rework due to high difficulty 
values. iicd 2t) pelts OWE) Drogrammers who consistently 
hav 


eS nigm ds ESoult values. This anables the manager to 
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ensure that the programmer receives added training in thea 
feemnigques @wailable to reduce program difficulty. IBM has 
POaund that the difficulty measure tends to range frem three 
26 eBoght. Wren ever they see that a difficulty measure 
exceeds five, they call the programmer in to have him/her 
recsode the program to reduce the difficulty measure to five 
or less. If the programn2r consistantly delivers code with 
high difficulty measures he/she is provided aided training 
in techniques which can lower the program difficulty. 

All this only gives measures of the program not ths 
prodcuctivity of the programmer. For IBM to datermine that 
all programmers had the sane productivity, they had to test. 


The test measure was and continues, On a Minor basis, to bs 


LOS per person-year. LOO is defined as data declarations 
and executable statments. The use of this measure, now, is 


only to check for changes in productivity due to new tools 
and zor reasonable production rate ralative to the industry. 
TBM recognizes the comparability problem of the LOC measure. 
However, «he IBM perceiv2i industry average ranges between 
a@0 same 2500 LOC per year, given the line counting varia- 
tons’. They continue to neasure productivity using LOC pez 


man-year to ensure that IBM remains wihtin this range. 


2. sAmdahi 


as Systom Softwarcrs 


Am@Gahi'ts approach <+¢o systems software develop- 
ment is different from most of the industry. AS 3 
manufacturer of IBM compatible hardw2res and software, their 
epe@eeie@eh +5 £O USe IBH software proiucts and modify them to 
Operate more efficiently on Amdanl hardware. This means 
placing "hooks" into the IBM softwacs to operate special 
Amdani procedures. Since their goal is develop more effi- 


ciant software, these hooks must be minimal in both length 
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and interference with the existing software and logic. 
Amdanl places a much higher emphasis on quality than 
quantity. 

In this light, none of the previously discussed 
measures apply. Amdahl uses a management by objectives 
(M380) approach to measur perf ormance:. Their hiring prac- 
ises aim towards acqyuicing thos programmers who are 
experienced, skilled ani senior in the industry. The 
programmers are organiz21 into jroups of two to threes 
assigned to one team leader. Each group has its own area of 
responsibility fcr program development/modification. ahe 
assignment or tasks and the time soastraints are determined 
by mutual agreement betw2an the manager and team leader. 
The schedules are recorded and each programmer is evaluated 
on his/her perfcrmance. The evaluation is discussed with 
the respective programm2r at the periodic performance 
review. Since each group has specific areas of responsi- 
bility and those areas ire limited, any trouble reports 


rescived are easily assign3d *> cth2 group and/or individual 


responsible. These are 2lso included in th2 performance 
review. This scenario ides allow any specific measure to 
quantizy programmer perfornance. However, the programming 
section is a small organization, 50-75 programmers, so they 


tzack the type of modification against the time required and 
a= Quality of the programaing. Th2y do not use any parti- 


Cular measure outside of budget and schedule. [Ref. 33] 
B. Kkepl2éataons 52 ftwarte 


Amdahl's application program development is ver 


(D 


Si@iiar <o the systems software development in that they us 


my 


MBI as the oredominant measure. They dec use LOC pe 
programmer year to do some measuring but it has very little 
Siac amcernce %0 the oper: tion. be wees deranged) es 9 vail 


Srogrammer-origimail COBOL statments. No credit is given for 








reused code, although, they admit some credit should be 
gier. This wculd appear to iscourage reusing code but 
their incentive, ceward and penalty system provides thse 
necessary encouragement. How the system functions was not 
specified. Management do2s require programmers to use data 
distionaries, and code libraries ars kept in an on-line data 
base. The primary measure used to neasure performance is a 
review ci the programmer's scheduls. The programmer submits 
a schedule of task acconolishment ¢95 the manager. Th 


(vb 


Manager reviews it to e2nsura it is realistic and then 
compares the schedule to the ‘task sompletion jates as the 
programmer delivers the assigned tasks. Here, as in systems 
developmen¢, the primacy ingr2dient for measuring is 
programmer and manager experisnce. “Ref. 34] 

The measure used t> evaluate Maintenance 
PeogmeeBong 21S buzit around the naunber of trouble reports 
Seeserved. ach prograWBing group is responsible for nainte- 
nance of its assigned software. T3an leaders must emphasiz= 
high quality in the software to avoid having to rescheduls 
DroOqdLrammers OntS Maintenance from development. This does 
RCO; DLUGVeEn= errors but it does cut them down. The main 
emphasis from the Applications Projramming Manager is ¢t9 
ensure as rapid a respons? time as possible on the trouble 
reports. re requizcea “H&#rcn@round oMe for trouble reports, 
beSeemety, is not to exces2d six montas. They use the turna- 
round measure because it tands to inijiicate to the users that 
tn2 company is genuinely interested in the productivity of 
software maintenance. [+ 2lso gives the respective managers 
an at@agi-ioral reason when requesting mor r2sources. 
Finaily, iz gives a busin2ss value £9 organizsd main*enance 
pezrause it forces the various managers to schedule resources 


for program maintenance. 





Amdahl uses program paskages predominantly in 
their applications progranning section. These packages come 
with their own documentation which allows Amiahl to takes 
femee an “epproach Significantly differant from this research- 
er's view point. Amdahl believes prograa code and 
documentation to be separate and uasqual products. This 
belief is made pessible because they have programs that can 
analyze code andteli th programmer the structure of the 
C@ac. therefore, they feel that program maintenance 
woltnout the documentation is not as difficult one might 
assume. However, docum2nation is zncouraged. The method 
used is to request documentation ani to make it as easy to 
provide as possible. To make the documentation easier, it 
is all written on-line using Script and a variety of user- 
developed macros that provide som2= graphics +9 enhance «hs 
prose. The documentation yuality is 29w much higher and the 
decumenzation is much easier for the programmers to deliver. 
(Ref. 34] 


3. Swed 


if 


ms Development Corporation (SEC) 


SDC's cost estimating proceiures use LOC and pages 
Ge @ecm@entat=on as th prigary oroductivity inputs to 
conpute costs. They catzgori:ze ths various types of LOC 
(data definitions, executable statements, reused code, etc.) 
'O @ete Meme the subtask cost for 23ash activity. Themis 
ars weighted by an in-house sonpleaxity méasure which 
includes parameters for program siz, security, and reli- 
apilsty. Fach productivity measure is computsi relative +9 
mee gYee of program (real-time prosess control, interactive, 
feocrce Generator, data bas2 control, etc.) that was 
pro Guced. Documentation is mesur2i by pages produced per 
Gay per type cf program. Although they call documentation a 
separate product, they consider all projects t> be inte- 
Geatea packages of both software sode and documenta*ion. 
(Ret. 3573 
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TRW uses a2 weighted LOC 2co man-month method to 
measure productivity. They raview2i Hdalstead's metrics but 
concluded, as did IBM, that sdurcé LOC is equivalent to the 
size metrics developed from counting operators and operands, 
They do concede that the difficulty metric daserves more 
Stidy but they have no resources avialable at present to 
eemamet such a study. They have found that weighting the 
Peo mick @m iin house factor for somplexity and reliability 
2s sufficient. The LOC is defined as 2 delivered well docu- 
mented and well engineered lin2 equal to a card image. The 
Cetd image is an eighty csharacter lins. Comment lines are 
not included but all lines which hold "computing" informa- 
clon ere #e.3. jieeeconeso lL banguag>, edit links, format 
statements, data declarations, exscutable statenants, etc.). 
TRW defines a man-month, 152 hours, ts include all personnel 
howes directly chargeabie to the project. 

at present, TRW do2s not meaasur2 maintanance produc- 
tivity. However, the interview with Dr. Boehm (Ref. 36], 
Tecommended the methoi discussed in his book Software 
Bajipeer-ng Economics (R2f. 37]. This method equates the 
@pauel meintenance effort to the annial change traffic (ACT) 
multiplied by the astimatel development effor. ACT is tha 
Pesctier Of the sottware product's source instructions which 
Wmcrgo Change during a typical y2ar, either through addi- 


tom OF Modifica tion. 


[en tnemendges djaca@enmtation in its definition of 4a 
nO. AS cerresponas with tne philesophy of this 
Derieesener. ~T~RW does not creat softwear]e code and documentea- 
Beepeecmse pasate products but as integral parts or the 
SOLtWeze project. 
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V. CONCLUSIONS AND RECOSMENDATIONS 

This paper has attempted to point out the major areas 
which must be explored in order t 5 measure and discuss 
programmer productivity or software development produc- 
tivity. The manager anust decids what level of the 
organization he wishes to neasure. He then must determine 
what, specifically, the product is which that level is 
making. Betore proceeding any further, he should examine 
the quality assurance procedures and practices to ensures 
tnat they are both in us2 ard that they do establish and 
check for a minimum quality standard. From hers the manager 
can select the various inputs which he feels ar2 relevant to 
Study. The productivity rates he conaputes need to be stored 
=n adata base so that they may b=? used aS comparators 
against time and other organizations. Finally, each neasurs 


must be kep+ in the context of its anvironment. This condi- 


tion provides two functiois. PaaS ts 1+ keeps the measure 
meaningful. Second, by s2lectively shanging one element of 
the environment at a time, she manager can determine cause 


and ¢iftect relationships that can l3ad to establishing the 
optimum software development environnen. 

The LOC measures are poor for software development and 
lead to paradoxical So neMisioOn's in many instances. 
Renaining with any measurs that us2s LOC will tend to bind 
mie o@ogenizat#on to tethiodlogies rc2quiring the development 


e £Otel iy origimal cod2 2n every project. This wxll tend 


O 


tc prevent the use of mataprogramming and the development of 
PEIgtas famylies. Thes2= programning technologies show 
significant promise to reduce development costs and improve 


programming productivity icamatically. 
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Modular measures proviie the opportunity to explore and 
develop the metaprogramaing practice. They also have over- 
heads that must be accepted as development parsonnel learn 
the technology, the added effort required in the design 
phase, particularly for "small" projects, and the possible 
inefficient use of CPU tine due to aa increase in the number 
or LOC. These are small overheads t> pay if the development 
tine can be reduced by as nuch as Laiergan [Ref. 19] claims. 
The measure can be usei in conjunction with any other 
measure to help define th2 programming activity better. ate 
may be especially us2fil in conjunction with function 
points. 

im ciosing, it is apparent for the literature and tha 
discussions with the selacted industry corporations that 
there is no perfect ani correct measure or method for 
measuring programmer produstivity. However, the vital point 
to understand is that nearly all organizations do measure 
programmer productivity i1 soma fashion. Several organiza- 
tions admit that their methods lack some possibly importan* 
anputs OD vdarameters. JOwever, 2ach crganization does 
attempt *o measure productivity so that each can gain some 
Wedersterasng Of “he Ofgairization's particulac environment. 
Me=h en Undiee standing of the environitiant, each organization 

d e +o conceptualiz® the software devel- 
cCpmert process so <that the managec can make intelligent 
ass 


emei@es ebeut how it is affectei. 
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FUNCTION VALUE INDEX WORKSHEET Project 10: 


Project Naser 








Prepared by: 
Project Summary: Start Sate End Date Work-Hours Function Points Celivered or Desianed 
amie SSS ee a ee ee a AS ia 


« (from calculation). 


(ie Sec ae ee eee 





Function Points Calculation (Cel:vered or Sesiancd): 























nae Se eS oe lee 
Allocation estimated by Project Manager [ 
~“« 
Note: Definitions Delivered Delivered by Delivered Totals 
on back of forn. Delivered by Modifying Installing by Using (Identify 
by New Existing and Testing a Code | “preponderant 
Code Code a Package Generator Language) 
' { 
Inputs | aa ae ee SS ee 
Outputs (ian Ra cz 2, Cage | a! Saas 
Work-hours i ! Total 
Design , ee ee «| Unadjusted 
Implementation L Function 
om.) oe err ge ee eee Points 


Complexity Adiustzent: (Estimate degree of influence for each factor) 


On-line data entry is provided itn 


Relishle backun. recovery. and/or Siva Hag ita lida. 


system availability are provided 
by the application design or 
implementation. The functions 
may be provided by specifically 
deaigned applicatios coce or by 
use of functions provided by 
standard software. For example, 
the stancard 22S backus and 
recovery functions. 


On-line data entry is provided in 
the application and in additicn 
the data entry 15 conversational 
Yeguiring that an input trans- 
action be built up over multiple 
Operations. 


Master files are updated on-line. 


Data communications are provided 


in the application. inputs, outputs, files, or 


inguiries are complex in 


® vd 
Distributed processing functions thid applications 


are proviced in the application. 


Performance must te considered 


in the design or implementation. Internal processing is 


In addition to considering in this application, 


performance tnere is the ecded 
cesplexity of a heavily vtilizcd 
opcrational configuration. Tha 


ee ee ee Ee Degree of Influence on Functicn: 
0 
1 
2 


Nonc 3 Average 
Incadental 4 Significant 
Modcrate 5 Essential 


application on cxisting or 
committed hardware that, as a 
consequence, will be heavaly 
utilized. 


Total Segree of Inflcence (N) 


Complexity adjustment equals (0.75 ¢ 0.01 (N)) 


Unadjusted Total X Complexity Adjustment © Function Points Delivered or Designed 


x 2 
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finitiona: 





General Instruction: 


Count all inputs, outputa, maater filea, 
inguiriea, and functions that are made available 
to the Ccuatomer through the project’s design, 
programaing, or testing efforta. For example, 
count the functions provided by an IUP, FOP, or 
Program product if the package was modified, 
integrated, tested, and thus provided to the 
euatomer through the project‘’a efforts. 


Work-hours: 


The work-houra recorded should be the IBM and 
customer hours spent on the oP Services 
standerd taska applicable to the Project phase. 
The customer houra should be adjusted to IBM 
equivalent hours conaidering experience, 
training, and work effectiveneaa. 





Input. Count: 


Count each system input that providea buainess 
function cormunication from the usera to the 
computer systen For example: 


e acanner forms or cards 
e keyed transactions 


@e data forms 
@ terminas ecrvens 


Do not double count the inputs. For example, 
conaider a manual operation that takes data 
from an input tcra, to form two input screens, 
vaing a keyboard to form each screen before the 
entry key 18 pressed. This snould be counted 
as two (2) inputa not five (5). 


Count all unique inputs. An input transaction 
ahould be counted as unique 1f 1t requircd 
different processing logic than other inputs. 
For example, transactions such as add, delete, 
Or change may have exactly tne same screen 
format but they should be counted as unique 
inputs if they require different procesaing 
logic. 


Do not count input or output terminal screens that 


are needed by the system only because of the 
specific technical implementation of the 
function. For example, OMS/VS scrcens, that 
are provided only to get to the next scrcen 
and do not provide a business function for the 
user, should not be counted. 


input and output tape and file data 
are included in the count of files. 


Do not count 
aeta. These 
Do not count These are 
covered in a 


inquiry transactions. 
subsecguent question. 


Output Count: 


Count each ayatem output that providea buainesa 
function communication from the computer syatem 
to the uaera. For example: 


a printed reports 


@® terminal printed outpu 
@ terminal screena 


@ Operator mesaagea 


Count all unique external outputs. An output is 
conaidered to be unique af it has a format 

that differa from other external outputs and 
inputs, or, if 1t requires unique processing 
logic tO provide or calculate the output data. 


Do not include output terminal acreens that 
provide Only a aimple error message or 
acknowledgement of the entry tranaaction, 
unlesa significant unique proceasing logic 

is required in addition to the editing 
asaociated with the input, which waa counted. 


Do not include on-line inquiry tranaaction 
outputa where the response occurs immediately. 
These are included in a later question. 


re  D 
File Count: 
Count each unique machine readable logical 


file, or logical grouping of data from the 
viewpoint of the user, that 18 generated, 


uaed, OF maintained by the ayatem. For 
example: 
@ anput card filea @ tape filea 


e disk files 


Count major user data groups within a data base. 
Count logacal files, not pnysical data sets. 

For example, a customer file requiring a 
secarate index file because of the accesa 
method would be counted as one logical 

file not two. FHecwever, an alphabetical 

index file to aid in establisning customer 
identity would be counted. 


Count all machine readable interfaces 
to other system as files. 





Inouiry Count: 


Count each input/response couplet where an on- 
line input generates and directly causes an 
immediate on-line output. Data is not entered 
except for control purposes and thercfore only 
transaction logs are altcred. 


Count each uniquely formatted or uniqucly 
processed inquiry which results ina file searce 
for specific information or summaries to be 
prescntced as response to that inquiry. 


Do not also count inquiries aa inputa or 
outputs. 
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DP SERVICES DESIGN PHASE Section 6.2 
SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM — 12-31-18 


Customer: Project ID: 


eart-™ Po 


Project Description: 


Prepared By: Date Prepared: 


When Prepared: (check one block) 


Before any Phase Completion 
Requirements Complete 

External System Design Complete 
Internal System Design Complete 


Coding Specs Complete 
Integration Complete 
System Test Complete 
System Demo Complete 


~~ on om 
ae ae ee eed 
~~ oo 
gt el eed Wel 


DESIGN PHASE 
SIZE AND COMPLEXITY 
FACTOR . 
ESTIMATOR FORM 


DP SERVICES 
DATA PROCESSING DIVISION 
IBM CORPORATION 





DP SERVICES DESIGN PHASE 
SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 


Section 6.2 
12-31-78 


QUESTION DEFINITIONS 


a. 


2. 


SCOPE OF THE INVOLVEMENT WITHIN THE COMPANY 


a. 


Company Functional Organizations: 


Identify the number of independent organizational entities which 
will be involved either directly or indirectly in the project 
For example, if the system includes two business functions 
inventory control and billing, at least two organizations 
probably would be involved. Direct involvement refers to actual 
participation in the requirement study or design. Indirect 
involvement refers to review and approval of the requirements or 
design. The organizations may be counted separately in each 
location. For example, if the accounting department has a 
subdepartment in each of three geographic locations, and if each 
must either be interviewed or included in the approval cycle, 
then the accounting function should be counted as three 
Organizations rather than one. Always include the data 
processing Organization. 


Company Locations: 


Identify the number of company locations that require travel for 
information, interviews or approvals. The primary location must 
also be counted. Each city involved would be a location. Where 
multiple locations exist in the same city, consider each as half 
a location. 


Number of people in the organizations involved: 


Identify the number of hundreds of people in each organization 
identified in question la) above. For example, a project 
involving two organizations, one with 135 people, and one with 50 
people would count as three hundreds of people. This provides a 
definition of complexity of interviews and requirements 
definition. 


FUNCTICNAL SIZE OF THE APPLICATION 


a. 


Number of Major Subsystems: 


6) 
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1. SCOPE OF THE INVOLVEMENT WITH THE COMPANY 


a. Number of company functional 
organizations involved: x 4 


b. Number of company locations 
involved: x 12 = 





Cc. Number of 100 (s) of people in 
the involved organizations: x 2 = 
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In general, a major subsystem is equivalent to a major 
application or system function. Examples of subsystems within an 
Order Processing System might be: 


Order Entry 

Accounts Receivable 
Inventory Update 
Inventory Replenishment 
Shipping 

Recovery and Restart 
Invoicing 

Management Reporting 
File Administration 
Pile Conversion 


If you think that a function is logically separable and 
reasonably significant in size then count it as a subsystem. 


Number of External Inputs: 


This question addresses all system input vehicles that provide 
business function communication from the users to the computer 
system (e.g., data forms, terminal screens, keyboard 
transactions, optical scanner forms). It does not include 
internal inputs such as tape and file data sets. These are 
included in the count of files. It should not include input 
screens that are needed by the design only because of the 
specific implementation (e.g., DMS/VS screens that are only 
provided to get to the next screen but do not provide input of a 
business function or business information for the terminal user.) 


It should include the inputs associated with all the functions 

committed in the design. If such functions as File Conversion 

and Data Base Maintenance are to be supported their inputs must 
be counted even if they are used only once. 


On-line inquiry transactions should not be counted here since 
they are included separately in a later question. 


The objective of this question is to enumerate all unique inputs. 
An input transaction should be counted as unique if there is any 
possibility that it will require different processing logic than 
Other transactions. For example, transactions which have exactly 
the same screen format and differ only in a code used to indicate 
transaction type (e.g., add, delete, change) should each be 
counted separately as unique transactions. 


Number of External Outputs: 
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2. FUNCTIONAL SIZE OF THE APPLICATION 


a. Number of Major Subsystems: 210 = 





b. Number of External Inputs: x 3 = 
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As with the External Inputs this question addresses all system 
output vehicles that provide business function communication from 
the computer system to the users (e.g., printed reports, output 
screens, hard copy terminal output operator messages). On-line 
inquiry transactions, where the response occurs immediately on- 
line should not be included in this count. However, printed 
reports which are triggered by off-line or on-line inquiries 
should be included in this count. The count should not inlcude 
Output screens that are needed by the design only because of the 
Specific implementation (e.g., DMS/VS screens that are only 
provided to get to the next screen but do not provide a business 
function or business information for the terminal user.) 


An output is considered to be unique if it has its own format 
which differs from other external outputs, or if it requires 
unique processing logic to provide or calculate the output data. 


Number of Files: 


This count should include each planned unique machine readable 
logical file, or logical grouping from the viewpoint of the user, 
that iS to be generated by or input to the system (e.g., card 
types, data base files, disk files, tape files). This question 
is Oriented toward logical files not physical data sets. For 
example, a customer file requiring a separate index file because 
of the access method chosen during design would be counted as 1 
logical file not 2. However, a special alphabetical index file 
to aid in establishing customer identity would be counted 
separately. 


This count should include all machine readable interfaces to 
other computer systems. 


Number of On-line Inquiry types: 


This question addresses conversational input/response couplets 
where the on-line input generates and directly causes an 
immediate on-line output. These couplets generally do not enter 
data except for control purposes and therefore alter only 
transaction logs. 


In determining this count consider each uniquely formatted or 
uniquely processed inquiry (input/response pair) which results in 
a file search for specific information or summaries of groups of 
information to be presented as output response to that inquiry. 


Inquiries should not also be counted as inputs or outputs. 
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3. COMPLEXITY OF THE OVERALL DESIGN PHASE 


a. 


Customer Capability: 


Consider whether the customer has data processing or user 
Capability that will provide a good environment for requirements 
definition and system design or whether his people will require 
more that normal explanation and justification for routine 
decisions. 


On the Other hand does the customer have so much expertise that 
his design convictions will complicate the job beyond that 
normally expected. (e.g., an application well suited to IMS but 
the customer wants to develop his own TCAM data base system.) 


Both situations would hinder the project. 
Existing Customer Function: 


Does the customer currently perform the business functions that 
are to be included in the System or is this a new business area? 


An example of a new function that would result ina "no” anSwer 
would be, an insurance company that does not currently handle 
group dental plans but wants to develop an automated system to 
process group dental claims so that they can compete for that 
type of business. 


Existing EDP Systems: 


If the answer to the previous question was No, then this question 
must also be anSwered No. If the customer currently is 
performing the majority of the business functions to be included 
in the system and a significant number of these are being 
Supported by existing EDP System(s), the answer should be Yes. 
Otherwise, the answer is NO. 


PErse Of d ‘Kid: 

Has this application ever been computerized before, anywhere? Is 
this the first attempt to automate a Significant business 
function in the application? A Yes to either question should 
make this system the First Of a Kind. 

Hardware and Software Operational Environment: 


This question is addressing the overall complexity of the 
estimated operational system. An example of a Simple system 
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3. COMPLEXITY OF OVERALL DESIGN PHASE 


a. 


b. 


Cc. 


d. 


Will the customer's capability hinder: 
No (0), Yes (10) 





Existing customer function to 
be automated: 
No (10), Yes (0) 


Does an EDP system exist now 
to perform the function: 
No (6), Yes (0) 


Is this system the first of its 
kind anywhere: 
No (0), Yes (10) 
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environment would be S/370 Models 115 or 125, DOS or DOS/VS and 
the IBM Standard TP and data base products that operate on that 
level CPU. 


An example of an In Between system environment would be $/370 
models 135 or 145, DOS, DOS/VS or OS/VS and CICS or DL/I or 
something equivalent. 


Large computers or more sophisticated operating System (e.g., 
MVS) or TP or DB environment (e.g., IMS or TCAM) would be 
considered aS Complex. Distributed processing and programmable 
terminals would also be considered complex. . 


&. SOPHISTICATION EXPECTED OF THE SYSTEM 


ae 


In answering the availability question consider how important it 
is that the system be kept available to the users. The whole 
data processing system including communications and terminals 
should be considered. Can work be postponed? 


Will components be duplicated to increase system availability? 
This can indicate critical availability. Will the system be 
designed to recover quickly from failure? This can indicate 
important availability. 


A batch system usually requires normal availability. A data 
collection system with non-perishable inputs, such as paper claim 
forms, miqnht justify important availability. A passenger 
reservation system or bank funds transfer system might require 
critical availability. 


Will a major or important design consideration be, that each 
Operation or function identified as critical have an alternate 
method. The alternate may involve manual operations and may take 
longer but the function is provided. 


Will the system contain data that must be protected against loss? 
Will the function require special recovery design in either 
procedures or system? If so, the answer is yes. 


Data Traffic Load or System Performance: 


In some systems, the volume of data to be handled is not a design 
concern. Other systems require special design considerations 
such as: use of file access optimization, simplified input 
notation, or extensive use of exception reporting. Transaction 
rates may be a problem in either on-line or batch systems. Large 
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Hardware and software system 
operational environment to be 

required by the application: 

Simple (0), In-between (5), Complex (10) 


@. SOPHISTICATION EXPECTED OF THE SYSTEM 


Availability is: Critical (8), 
Important (4), Normal (0) 

Is an alternate method, for 
performing the functions of the 
system, non-routine consideration: 
No (0), Yes (6) 

Is system recovery or protection 
against data loss a non-routine 
consideration: 

No (0), Yes (5) 
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volumes of data in short periods (peak loads) or volumes of data 
large enough to cause machine availability problems are all 
considered data traffic considerations. . 


System performance is often a significant design consideration in 
systems that are intended to handle large volumes of data. It 
can also be of major concern in the design of systems with 
relatively low transaction rates but with constraints (perhaps 
economic) in terms of the prescribed hardware and software 
environment. For example, there may be limitations on the size 
of main storage, control program multi-programming capabilities, 
or transmission line speeds. 


Nature of the Application: 


A batch system operates as a job shop, often scheduled. 
Transactions are typically batched external to the computer and 
periodically processed sequentially against the master files. 


An on-line system generally requires a more sophisticated 
man/machine interface than a batch system. It is generally a 
System where transactions are entered as they are received with 
no opportunity for time saving sorting. The inputs are not 
perishable (i.e., they can be re-entered if necessary). An on- 
line order entry system, or an on-line stock location and 
inventory control system would be examples of on-line. 


A real-time system is similar to an On-line system in that it is 
available on demand, but it has an additional requirement to not 
postpone its main line processing. Response time is 
exceptionally important. Immediate processing and response is 
necessary to meet the functional requirements of the system. 
Process control, production test stand control, and airline 
reservation systems are examples of real-time systems where 
degraded performance may cause lost production or lost bDusiness. 


Processing Complexity: 


This question addresses the internal processing logic required to 
provide the majority of the proposed system functions. 
Straightforward logic would involve simple transformations or 
mapping from the system inputs or files to the system outputs. 
For example, a transaction is read, verified to a limited degree 
and used to update a simple master file or to generate a simple 
report. Processing is a straightforward set of pre-specified 
rules. Few, if any, data transformations are done. Outputs are 
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dad. Is data traffic load or system 
performance an important 
design consideration: 
No (0), Either (10), Both (20) 


e. Nature of the Application: 
Batch (0), On-Line (10), Real-Time (20) 
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mostly collections in various sets, of established data from 
files. 


Complex should be checked if the system has a preponderance of 
exception processing resulting in many incomplete transactions 
that must be resolved later or again. Complex logic would also 
be the answer if there are many interactions and decision points 
and extensive logical or mathematical equations. In-between is 
used if it fails to meet either of the above definitions. 


Exception Correction: 


Systems which are designed primarily to process correct data and 
to detect and present bad or unusual data for manual review and 
correction are manual exception systems. If the system is to be 
designed not only to detect, but also, automatically to correct a 
Significant number of unusual conditions, the system is an 
automatic exception system. This is true even if the options 
selected or corrections applied are to be reviewed and verified 
manually. 


5. KNOWLEDGE WE HAVE FOR THIS PROJECT 


a. 


= 


Consider the Services Area in general and specifically the people 
who may influence the project through: 


Project Management 
Proposal Preparation 
Systems Assurance 
Project Team Performance 


Consider the Area's current knowledge and the available Industry 
knowledge. If none of the people in the performing Area have 
designed or implemented this type of application before, the 
answer should be Completely New. If informed consultation and 
review is available with people in the Area the answer should be 
Some Familiarity. If Services people, clearly expected to 
participate Significantly in the proposal and project, are 
currently assigned to the performing Area and have recently 
performed on a Similar project the answer may be Have Done 
Similar Job Once. 


To answer Extremely Thorough the proposal should contain a 
technical baseline that shows excellent understanding of the 
tasks in the Statement of Work. The Customer User, IBM Branch, 
and DP Services mst have contributed and concurred with the 
approach. Everything else should be moderate unless we lack 
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“IY 


f. Processing complexity: 
Straightforward (0), 
Complex (30), In-between (15) 


g.- Exception Correction is mostly: 
Manual (0), Automatic (20) 


9. KNOWLEDGE WE HAVE FOR THIS PROJECT 


a. How familiar is the proposed 
Services Area with this Application: 
Completely New (30), Some 
Pamiliarity (15), Have done 
Similar job once (0) 


f? 
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customer agreement either through lack of contact or because of 
direct disagreement. 


6. READINESS TO PERFORM THIS PROJECT 


a. Consider the location of the project with respect to the home 
location of the people expected to work on it. Unless local 
commuting habits and ground rules indicate otherwise, travel of 
more than one hour each way to the work location should be 
considered Significant Commuting. 


b. Consider the proposed manning on the project. Normally the 
manning On DP Services projects comes from DP Services, the IBM 
Branch, or the Customer. If the manning is proposed with 
elements other than these, (1.e., subcontract or shop order) mark 
an equivalent answer from the viewpoints of Project Management 
control and the resource’s ability. 


c. All temporary or permanent moves of project team members should 
be considered whether they involve IBM people or customer people. 


¢ 


THE SIZE AND COMPLEXITY FACTOR COMPUTATION: 


To compute the Design Phase Size and Complexity Factor that will be used 
to validate the task-by-task estimate follow these steps: 


1. Review and sum up the weighted answers to the questions to 
determine factors Fl through Fé. 


2. Enter F1 through F6 and evaluate the equations on page 19. 


3. Sum the results of (1), (2) and (3) to obtain the Design Phase 
Size and Complexity Factor. 


ESTIMATE VALIDATION: 


Use the Design Phase Size and Complexity Factor and the plots provided 
in Section 6.2 to determine the average number of hours that the 
Standard tasks took on completed DP Services projects with similar 
Design Phase Size and Complexity Factors. Enter these hours in the 
appropriate Dlanks on page 20. 


If the data is sparse, the information on each standard task may not be 


provided as a Separate number. However, the hours spent on that task 
are in the totals and in the associated standard task. (e.g., the hours 
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Services Preproposal Analysis: 

Extremely thorough (0), 

Moderate (10), NO customer agreement with 
approach (20) 


6. READINESS TO PERFORM THIS PROJECT 


a. 


Where is project to be located: 
NO unusual commuting (0), 
Significant Commuting (5), 
Temporary or permanent moves 
required (10) 
Manning: 
All Services (0), Mixed IBM Manning (5), 
Customer and IBM Mixed (10) 
Number of temporary and permanent 
moves required 
KO a a ae 
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for implementation planning may not be separately identified, but they 
would be in the internal system design task and in the total hours.) 


Map the task-by-task eStimate into the same standard tasks and compare 
the estimates. The Proposal Manager should analyze and explain any 
differences or make the appropriate adjustments in the task-by-task 
eStimate and the proposal. 


FEEDBACK PROJECT RESULTS: 


After the project is completed and the PCAR is available, adjust the 
Design Phase Size and Complexity Factor. The factor needs to be 
adjusted to account for changes (approved PCR(s)) that occurred during 
the project. This adjustment provides a factor that should be related 
to the completed project's results: 


Original S&C - The original size and complexity factor computed 
at proposal time on page 19. 

Change Hours = The total estimated hours of approved changes 
taken from the PCAR. : 


Total Yours 
Multiplier = The current factor multiplier for the total 
hours plot in the design phase estimator. 


Adjusted S$ &C The size and complexity factor used for project 
feedback of results adjusted for the approved 


changes. 


Adjusted S &€C 


Change Hours + Original S & C 
Total Hours Multiplier 


The results of the completed project standard tasks and the delivered 
reports are also taken from the PCAR. If the project does not represent 
a complete design phase, the numbers must be used with care. (e.g., a 
requirements only deSign phaSe can give a good requirements number. It 
certainly won’t give any design numbers. Less obviously, it won't give 
any management numbers or total hours numbers either). 
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THE SIZE AND COMPLEXITY FACTOR COMPUTATION: 
1. Orientation Factor: 


¢ ») (100 + ¢ »> + { )) x .9/1000 = 
F1 FS F6 


2. Requirements Analysis Factor: 


( » (100 + ( ee | ) 
F2 Fi F3 


+ ( 9/10 + (¢ > + ¢ >) x .6/1000 = 
F& FS F6 


3. System Design Factor: 


( ») (100 + ( \/2 + ( 73 
F2 P3 F4 


>» 1 74) 1.771000 = 
F5 


= 


Size and Complexity Factor = 


= a a SPS SP SP Sa oe oO 


Sum(1) , (2), (3) 
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Prom 
S & C Factor 


Total Hours 
System Design 
External System Design 


Internal System Design 
Implementation Plan 


Requirements Definition we 
Orientation 

Management 

System Design Report Size 


Requirements Report Size 


_ 
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Task-By-Task 
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FEEDBACK OF RESULTS: 


Adjust Size and Complexity Pactor: By: Date: 
( »> + ( » = ( ) Adjusted Size and Complexity 
_— Factor 
Completed Project Results: By: Date: 


Total Hours 
System Design 
External System Design’ 
Internal System Design 
Implementation Plan 
Requirements Definition 
Orientation 
Management : 


System Design Report Size 


Requirements Report Size 
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